Sufficient FTP Schedulability Test for the 
Non-Cyclic Generalized Multiframe Task Model 



In this paper we consider the schedulability of the Non-Cyclic Generalized Multiframe 
Task Model System Model defined by Moyo et al. QZtl (nc-gmf in short). Moyo et al. 
provided a sufficient EDF schedulability test, Baruah extended the model by considering 
the Non-cyclic recurring task model Q]] and provided an exact feasibility test. Stigge et 
al. further extend this model and consider Digraph real-time task model [8 ], and consider 
the feasibility (or, equivalently the EDF-schedulability) of their task model. 

Formally, an nc-gmf task set r is composed of M tasks Jt 1 , . . . , t m }. An nc-gmf task 
Ti is characterized by the 3-tuple (C i: %) where Ci, D i} and T[ are iV-ary vectors 
[Cj 1 , Cf, . . . , C^} of execution requirement, [D\, Df, . . . , Df 1 } of (relative) deadlines, and 
[T/, Tj 2 , . . . , T t Ni ] of minimum separations, respectively. Additionally each task makes an 
initial release not before time-instant Oj. 

The interpretation is as follows: each task T; can be in N t different configurations, 
where configuration j with j e {1, . . . , Aj} corresponds to the triplet (C(, Df,T?). We 
denote by l\ e {1, . . . , A^} the configuration of the k th frame of task n. The first frame of 

task Ti has an arrival time aj > Oi, an execution requirement of cf* , an absolute deadline 

a] + D\ l and a minimum separation duration of t/ 4 with the next frame. The fc* frame 

has an arrival time af > af + , an execution requirement of , an absolute 

deadline af + and a minimum separation duration of T i i with the next frame. 

It is important to notice that t\ can be any value in {1, . . . , A*} for i e {1, . . . , M} 
and k e Nq". I.e., the exact order in which the different kinds of jobs are generated is 
not know at design-time, it is non-cyclic. In this way this model generalizes the gmf 
model M- 

In this research we consider the scheduling of nc-gmf using Fixed Task Priority (ftp) 
schedulers and without loss generality i < j implies that r< has a higher priority than 
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1 Introduction 



Tj. Notice that, while having a model and solutions close to ours, |]8]] considers dynamic 
priority tasks. Even if a very similar mechanism (the request bound function) works 
very well with dynamic priorities allowing one to provide necessary and sufficient fea- 
sibility tests, it introduces some pessimism with fixed priorities, leading to a sufficient 
schedulability test. 

This research. Our goal is to provide a sufficient schedulability test — ideally polynomial — 
for the scheduling of nc-gmf using ftp schedulers. We report two first results: (i) we 
present and prove correct the critical instant for the nc-gmf then (ii) we propose an 
algorithm which provides a sufficient (but pseudo-polynomial) schedulability test. 

2 Critical Instant 

First notice that the popular critical instant notion (see Definition [T]) is not really appli- 
cable in our task model. 

Definition 1. A critical instant of a task T is a time instant such that: the job of T at this 
instant has the maximum response time of all job of Tj. 

This notion is difficult to extend to non-cyclic model in the sense that the workload 
(task requests) is not unique, contrary to the Liu and Layland or the (cyclic) gmf task 
model. 

Anyway, the critical instant is important because it provides the worst-case scenario 
from Tj standpoint, in the next section we will show that the synchronous case remains 
the worst case for the more general model namely the nc-gmf. 

Definition 2. Let us consider an nc-gmf task set {r, : i e [1, . . . ,M]}, where r, is de- 
scribed by 

{(Pi, D l T /)> • • • > (cf % D f^ T ^)}- 

The scenario of task n, denoted by Si, is a value a\ > Oi (the initial release time) 
associated with an infinite sequence of tuples nf) : k — 1, 2 . . . }, with: 

• e*e{i,...,Ni}, 

If task Tj follows the scenario Si, then: 

• the first job is released at time a}, has an execution requirement of 4 and a relative 
deadline , 

• the k th job (k > 1) is released at time a\ = a^ _1 +7rf _1 , has an execution requirement 
of and a relative deadline . 

In this work we consider offset independent scenarios with the following definition: 
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Definition 3. A scenario <Sj is said to be offset independent if it depends neither on a}, 
nor on the schedule. In other words, if we shift by A the first arrival, all arrivals will be 
shifted the same way, and the jobs will keep the same characteristics. 
A scenario Si obtained in shifting Si by A is described by: 
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Definition 4 (From [4]). An idle instant occurs at time t in a schedule if all jobs arriving 
strictly before t have completed their execution before or at time t in the schedule. 

Theorem 5. For any task the maximum response time occurs when all higher priority 
tasks release a new task request synchronously with t { and the subsequent requests arrive 
as soon as possible. 



Proof. WeQ consider a job J { in a given scenario and we will show that, by shifting the 
job releases of higher priority tasks, in the synchronous case the response time of the job 
Ji does not decrease. Since that property holds whatever the scenario we can conclude 
that the worst case response time occurs in a synchronous scenario, hence the property. 

Let t be the Ji release time. Let £_i be the latest idle instant for the scheduling 
of n, . . . , Tj at or before £ - Let t R denote the time instant when Jj completes. (See 
Figure [TJ) 

First, if we (artificially) redefine Ji release time to be t _i then t R remains unchanged 
but the Ji response time may increase. 

Assume now that r, releases a job at t _i and some higher priority task Tj does not. If 
we left-shift r, such that its first job is released at time t-i then Jj response time remains 

1 This proof is based upon lecture slides, the authors thank S. Funk and J. Anderson. It corrects 16]| 
for the popular sporadic task model. 
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Figure 2: (a, b, c): Request bound functions (rbf) for a task r* with Q = (1,2) and 
it = (2,5). In (a): S = (1,1,1,1,...), in (b): S = (2,2,...), in (c): S = (1,2,1,1,...). 
(d): Maximum request bound functions (mrbf) (all the request bound functions are in 
light gray), (e): Maximum request bound function for task Tj with Q = (4,6,3) and 
if = (5, 10, 4). The two oblique lines are ub, and LBj (using Equation]^. 



unchanged or is increased (since we consider offset independent scenarios). We have 
constructed a portion of the schedule that is identical to the one which occurs at time i_i 
when n, . . . , Ti release job together. This shows that asynchronous releases cannot cause 
larger response time than synchronous release (for the same scenario) . 

It remains to show that the left-shift does not impact on Li. It may be noticed that 
no job shift pasts £_ ls every job that starts after t _i continues to do so after the shift by 
construction. Similarly, any job that starts before t _ a continues to do so after the shift 
and t-i remain an idle instant: for each interval [x, t _i], no job shift into this interval, no 
left shifts cross therefore the total demand during [x, cannot increase, therefore 
the last completion time prior to £_ a cannot be delayed. 

The same argument (i.e., the left-shift) can be used to complete the proof and show 
that the worst case response time occurs when the subsequent requests arrive as soon as 
possible. □ 



3 Schedulability Test 
3.1 Request Bound Function 

In order to provide a schedulability test, we will use a similar approach to the one used 
by [|9l IS lU , in order to bound the computation demand that a task can request. From the 
previous section, we know that a scenario has its worst demand when the first request 
arrives at time 0, and all other requests arrive as soon as possible. I.e., aj = and 

ti f = T i i . This kind of scenario will be called a dense scenario. 

In the following, we define a sporadic scenario as a scenario were exact release times 
are let free. A sporadic scenario is then determined by a sequence of configuration 
numbers {£}, £j, ...} with l\ e {I,..., N { } Vi, k. Theorem § says then amongst all the 
possible arrival pattern of a sporadic scenario, the dense scenario is the worst. 

From this, we provide a new definition: 

Definition 6. Given a sporadic scenario of a task n, we define the Request Bound 
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Function RBF Si (t) as the maximal total demand that Tj can request in the interval [0,t]. 
Formally, 

«(*) k P 
RBF5- (t) = J^cf with a(t) = min{/3 > | J^lf 1 ' > £}• 

fc=i fc=i 

In the single frame model, where there is only one possible (sporadic) scenario, this 
corresponds to the Request Bound Function [3]. In the framework of feasibility for 
dynamic priorities, authors of fl8]] consider Demand Bound Function, instead of Request 
Bound Function. 

Some example of such request bound functions are shown in Figure [2](a)-[2](c). We 
can observe that a request bound function is always composed of a sequence of connected 

steps, where the k th step is composed of a vertical jump of C i i , followed by a horizontal 

segment of length T i i . 

Let us now assume that the (sporadic) scenario is fixed for all tasks r 1; . . . ,Tj 1, is 
proved to be schedulable, and we want to know if the system is still schedulable if we add 
a task Ti. Adapting the results from []9]|, we need to check that, if starting synchronously 
with all higher priority tasks, 7* can still meet its deadline. As n can have different 
configurations, we need to find the smallest solution to the following N { inequalities: 

* = C? + £rbf^(*) \/ke{l,...,Ni}. (1) 

If we now want to check the schedulability of any task system, we need to raise the 
hypothesis that the scenarios are known, and consider all the possible combinations of 
scenarios. But checking the schedulability through this method would be impossible 
within a reasonable amount of time, even for small problem instances. 

In the following, we propose to bound all the possible request bound functions for a 
given task, and to use this bound instead of all possible scenarios. This will make the 
problem tractable, but at the price of loosing the exactness of the schedulability test (as 



explained in Section 3.3) 



3.2 Maximum Request Bound Function 

In the following, we will focus on the maximal request that a task can produce in the 
interval [0,t), whatever the scenario. 

Definition 7. The Maximum Request Bound Function MRBFj(t) of a task r; represents an 
upper bound on the demand that task r, can request up to any time t. Formally, 

MRBFj(t) = max RBF CT (t) 
where {Si} represents all the possible dense scenarios of Tj. 
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Notice the mrbf is not the maximum of all the rbf's (such a maximum does not exist 
in general), but a function which, for each t, gives the maximum of all rbf(£). 

Examples of such mrbf functions can be seen in Figures |2](d)-[2](e). Before explaining 
how this mrbf can be practically computed, here is how we use it: 

Theorem 8. An nc-gmf task set r is schedulable using an ftp assignment if, Vz G 
{1, . . . , M}, \/k G {1, . . . , Ni}, the smallest positive solution to the equality 

t = C\ + ^MRBF j (t) 

j<i 

is not larger than D\. 

Proof. This is a consequence of Theorem [5] and the worst-case response time computation 
for ftp schedulers . □ 



3.3 Pessimism 

As we stated before, this technique introduces some pessimism. Here is a simple exam- 
ple explaining why. Let us consider a system with two tasks, where n is described in 
Figure |2](a)-[2](d), and r 2 contains only one configuration with C\ = \ and T\ = D\ = 3. 
A way of proving that this system is schedulable is to consider the rbf of all possible sce- 
narios for n, and to see if r 2 can process its single unit of work within the three first units 
of time. For every scenario a, it boils down to find a t < 3 such that rbf ct (£) + C\ < t. 
This is obviously the case for Figure ga) (t = 2), (b) (t = 3) and (c) (t = 2). We let 
the reader check the other cases. However, we could not find such a t with mrbf, which 
implies that our test could not conclude the schedulability of the system. 

As a future work, we would like to quantify this pessimism, i.e., study how much 
exactness we loose by considering mrbf instead of all the rbf's separately. We hope to 
be able to bound this pessimism by a constant C : if our test attests the non-schedulability 
of a task system r on a unit speed CPU, then it is for sure not schedulable on a CPU of 
speed C. 

3.4 Algorithm 

Computing MRBFj(t) can be done in a very similar way as in the context of dynamic 
priorities QSjl . We present the algorithm (Algorithm [p here for the sake of completeness. 

The basic idea is to store in a queue (Q) points where a (dense) scenario can pass 
(i.e., one step stops at this point. In Figure^, this corresponds to the rightmost point of 
a vertical segment). We first add the point (0,0) (line [2]), and then all the points that 
can be reached from (0,0), i.e., (T 1 , C 1 ), (T 2 ,C 2 ), . . . , (T^,C N ) (lines g through [To|) . Of 
course, we only add a point if it is not already in the queue, as observed in [8] (line [9]). 

Notice that we only need to get mrbf until the maximal deadline of tasks with a lower 
index, represented by A (line [5]) . 
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Algorithm 1: Computing MRBFj 
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Data: [C\ C 2 ,..., C N ], \T\ T 2 , . . . , T N \, A 

1 MRBF(t) = 0,Vt > 0; 

2 Q£(0,0); 

3 while Q not empty do 

(t,f) 4— Q ; II Q is ordered on t 
if t < A then 

foreach C*,T fc do 

t' <- t + T k ,v' <- v + C k ; 
Vx > t : MRBF(:r) max{MRBF(x), i/}; 
if (*', u') £ Q then 

L (*>'); 



ii return mrbf; 



3.5 Bounding mrbf 

In order to efficiently compute mrbf, as well as to give some approximation, it is useful to 
bound this function. Before giving some bound, we will first define some value. The max- 

def f 1 

imal slope is defined as Uf 1 '^ = max fc j # j • Notice that U" mx could correspond to several 

configurations of 7*. The maximal amount of work is given by Q nax = f max fc {Cf }. 

We also need to define Cf max , the computation requirement corresponding to the 
maximal slope (or the maximum of them if several configurations correspond to the 

maximal slope): Cf max d = max fc jcf : |f = f/f ax j. 
Property 9. V* : MRBF^t) < UB^t) d = Uf 1 ax x i + Cf iax . 

Proof. In order to prove that mrbf, is always below the line UBj, we will show that no 
scenario can ever have any point above this line. First, we remind that a scenario is 
a set of connected steps, each of them composed of one vertical jump of some value 
Cf, followed by a horizontal segment of the corresponding Xf . One step represents the 
contribution of one job of t { in its configuration k. 

The proof is done by contradiction. Let us assume that a scenario contains a point 
(t,v) above the line, i.e., such that UBj(t) < v. Without loss of generality, we can as- 
sume that this point is the left-most point of the segment it belongs to. By construction, 
this point is in the middle of the contribution of some configuration k of T i} and this 
contribution starts at (t,v - Cf). Note that as C* < C™ ax , this point is above the line 
f(t) = £/™ ax x t. We should now find a sequence ki,k 2 , ■ ■ ■ ,k n such that ^ . cf J =v — C\ 

and J2j rf 3 = t. This is impossible, as it would mean that, in average, the contributions 
of the jobs would have a slope larger than £/™ ax , which is a contradiction. □ 
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Property 10. Vt : MRBFj (t) > LB;(t) = f £/f ax x i. 

Proof. In order to prove this property, we simply build a scenario S which respects the 
condition Vt : S(t) > LBj(t). As by definition, MRBFj (£) > S(t) for any scenario S of r», 
this will make the proof. The scenario S consists in choosing infinitely many times the 
configuration with the highest slope, i.e., the one corresponding to U™ ax . Trivially, this 
scenario "touches" LB; on the right side of each horizontal segment. □ 

With a similar argument, we could refine our lower bound: 

LBj (t) = Ur x x t + (Cf ax - Cf ma * ) . (2) 
We let the formal proof for a longer version of this paper. 

Property 11. No scenario going through (t,v) such that LBj(t) — C max > v can ever 
coincide with MRBFj after t. 

Proof. From Prop. |9j a point below LB, — C* max will never be part of a scenario reaching 
LBj, for the same reason that no scenario of r, starting at (0, 0) can ever reach UBj. As 



MRBFj is always above LBj (Prop. 10), a point below LBj — (7 max will never be part of a 



scenario contributing in MRBFj. □ 

From this last property, we can strongly improve Algorithm [T} As soon as a point is 
too far from mrbf, it can be ignored. Line|9]of Algorithm [T] can be re-written as: 

if t' x U max < v' + C max and {t', v') $ Q (3) 

With the same argument as in []8]], we may prove that Algorithm [T] is polynomially 
bounded in A and n^. 



4 Open Questions and Conclusion 

In this work, we provide a sufficient schedulability test for the scheduling of NC-GMF 
tasks using ftp schedulers. 

There is still a lot of work to be done in that direction. Here are a few examples of 
our plans for the very near future. 

• We observed that starting from a value we still need to quantify, MRBFj follows a 
periodic pattern of size C'[ /max x T i f/max . We hope to find a fast way to compute this 
pattern and when it starts. This might allow strongly improving the complexity of 
computing MRBFj (t). 

• As already stated, our method introduces some pessimism that we would like to 
quantify, and hopefully bound. 
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• We would like to adapt the technique presented in Q3l| in order to define a polyno- 
mial approximation scheme for our schedulability test, combining MRBFj for k steps 
with UBj for higher values. However, the complexity of computing k steps of mrbf 
is much more complex than in Q3J where computing k steps is in 0(k). We will 
need to bound the complexity of getting k steps of mrbf; the previous item will be 
a first step before we get this result. 

• We also plan to adapt our technique to the more general model of Digraph tasks 
Il8ll . We believe that it should not be very difficult, but we will need to adapt the 
proof of the critical instant and the algorithms. 
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